Publishing and Release Management

• Use semantic versioning for human-facing versionName (e.g., 1.2.3).
• Increment platform build numbers (versionCode on Android, CFBundleVersion on iOS) for each release.
• Automate version bumps in CI or via a small script and store metadata in a single source (pubspec.yaml or CI variables).

• Create a signing key (keystore) and secure it: store in your secret manager, not in repo.
• Configure key properties in android/key.properties and reference them from build.gradle or supply via CI secrets.
• Build release AAB (recommended) or APK:
  • flutter build appbundle --release
  • flutter build apk --release
• Test the generated artifact on devices and internal testing tracks prior to production rollout.

• Register bundle identifier and provisioning profiles in Apple Developer account.
• Use Xcode or the Flutter build pipeline:
  • flutter build ipa --release or build via Xcode for archive.
• Configure code signing with automatic signing or supply provisioning profiles and certificates via CI secrets.
• Test on physical devices and run TestFlight distribution for beta testing before App Store submission.

• Use staged rollouts to limit exposure: internal testing, closed beta, open beta, then gradual production rollout.
• Monitor crash and performance metrics during staged rollout and pause or rollback if issues are detected.
• Apply feature flags and server-side toggles to gradually enable risky features without issuing a new binary.

Automation

Automate building, signing, and publishing with CI providers (GitHub Actions, Bitrise, Codemagic, Fastlane).

Use environment-specific build flavors and secrets per channel.

• Prepare high-quality screenshots for required device sizes and locales.
• Provide app icon variants, promotional graphics, and feature images as required.
• Craft concise, localized app descriptions and prepare a privacy policy URL.
• Fill content rating, category, and contact information accurately for compliance.

• Provide a privacy policy URL and ensure it covers data collection, storage, and sharing practices.
• Declare permissions and APIs used (camera, location, contacts) and provide justifications in store metadata and app prompts.
• Answer export compliance and encryption questions on App Store Connect correctly.
• Implement data deletion and export workflows if required by regional privacy laws.

• Integrate crash reporting (Sentry, Firebase Crashlytics) and analytics (Firebase Analytics, Amplitude).
• Monitor ANR, crash rate, and key user journeys after each release.
• Set up alerts for spikes in crashes or degraded performance.
• Collect user feedback and respond to critical reviews and issues quickly.

• For critical regressions, release hotfix builds with higher build numbers and limited rollouts.
• Use server-side feature toggles to disable failing features quickly without releasing a new build.
• Maintain a changelog and use semantic releases to track hotfix vs minor/major releases.

• Use build flavors (Android productFlavors, iOS schemes) to separate dev/staging/prod configurations.
• Inject environment-specific variables at build time (API endpoints, feature flags) via Dart defines or platform configs.
• Keep secrets out of source control and provision them via CI secret stores or secure key management.

• Generate changelogs from commit messages or PR descriptions and include plain-text release notes for store submissions.
• Use CI to attach artifacts and changelogs to release tickets or GitHub Releases for auditability.
• Tag releases in version control and link artifacts to tags for reproducibility.

• Validate builds on a matrix of devices and OS versions representative of your user base.
• Test critical flows offline, with poor connectivity, and under constrained resources.
• Use beta testers for broader coverage; incorporate feedback before wide rollout.

• Missing or incorrect signing credentials causing build/upload failures.
• Mismatched bundle identifiers or package names between code and store configuration.
• Forgetting to increment build numbers, causing store rejections.
• Hard-coded debug flags or test endpoints left in production builds.
• Failing to include required privacy or permission explanations in Info.plist or Android manifest.